[iOSDC Japan 2019 リポート]「iOSアプリのリジェクトリスクを早期に発見するための取り組み」を聞いてきた
こんにちは。きんくまです。iOSDC Japan 2019に参加しています。
これまでのレポート
- [iOSDC Japan 2019 リポート]「実機の管理とおさらば!AWS Device FarmでiOSのテストをしよう!」を聞いてきた
iOSアプリのリジェクトリスクを早期に発見するための取り組み
発表:DeNA 加瀬 健太さん @Kesin11
iOSアプリ開発は年々複雑化しています。次々と追加される新デバイスや新しいAPIへの対応など技術的な要因はいくつかありますが、それ以外にも更新され続けているApp Store Reviewガイドラインやその他のApp Storeに提出できるアプリの要件を遵守する必要があるのもその要因の1つです。
ガイドラインや提出できるアプリの要件は日々修正、追加されているため常に最新情報を把握することは難しいです。ですがこれを怠ってしまうと、いざリリースという段階になってリジェクトされてしまい、思わぬ対応コストとスケジュールの変更を余儀なくされる可能性があります。
この問題を解決するため、ビルドされたアプリに対してガイドラインやApp Storeに提出できるアプリの要件を遵守できているか機械的にチェックするツールを作成しました。このツールはFastlaneプラグインとして提供され、Fastlaneによるビルドパイプラインに簡単に組み込むことが可能です。ツールによるチェック結果はコンソールログ以外にHTMLレポートとして出力が可能で、検証を担当されているQAチームと連携してリリース前の段階でアプリに問題が無いことを確認しています。
iOS開発においてApp Store ReviewガイドラインとApp Storeに提出できるアプリの要件を満たすために気をつけるべき注意点と、今回紹介するチェックツールと同様のものを自作するために必要な知識を持ち帰ってもらいたいと思います。
スライド
前回 App Store Reviewガイドラインが更新されたのはいつ?
正解: 4-6月(具体的には6/3)
開発者や組織としてプラットフォームからのアナウンスを把握しておくことは大事
社内の開発・リリースフロー
- 開発
- 開発チーム
- 検証 / リジェクトリスク検査
- QAチーム
- アップロード
- アカウントホルダー
- 審査
- App Store Connect
- リリース
フローの後ほど問題が起きたときの手戻りが大きい
新機能が増えればReviewガイドラインも増える
リジェクトリスクを検査するFastlaneプラグインを作りました
AppChecker
- Fastlaneにビルド後のipaのパスを書くだけで簡単に導入可能
警告レベル
- error
- App Storeにアップロード時にエラーになる、あるいは審査時にリジェクトのリスクが高い
- 検知された場合は原則として修正必須
- warn
- info
チェックしている項目 - error
- iOS SDKバージョンが古すぎないか
- Xcodeバージョンが古すぎないか
- アイコンサイズが揃っているか
- PrivateFrameworkをリンクしていないか
AppCheckerをどう活用していくか
- Githubをプッシュ
- bitriseでビルド。AppChecker実行
- ビルド生成物
- ipa <- 検証
- HTMLレポート <- 確認
- App Store Connectにアップロード
- 審査・公開
- リリース
開発・QAでのチェックが自動化、省力化されました
ガイドラインを追い続ける方法
- Appleのデベロッパー向けNews
- 社内の過去のリジェクト事例を共有して横展開
- Reviewガイドラインが更新された際にdiffを取る
まとめ
- リジェクトリスクを検知する社内Fastlaneプラグインを作成しました
- チェック自動化により早期フィードバック、HTMLレポートによりQAチェックの省力化
- リジェクトによる手戻りをなくしていきたい
- App Store Reviewガイドラインは常に要チェック
感想
DeNAさんは、開発とQAチームがわかれているのが印象的でした。たぶん扱うアプリの本数や、アップデートの頻度がかなり多いためにそうなっているのかな?と思いました。
審査の前に、自社チェックツールを使うことで、手戻りを少なくする仕組みを解説されていました。そのツール内ではipaを解凍してコマンドラインで中身を精査していました。初めて聞くコマンド名が多く、こんなところまで確認できるのか!と驚きました。
また、AppleのDeveloper Newsを社内Slackに流すのも、開発側が自然とReviewガイドラインなどについて意識できる良い仕組みだと思いました。(ガイドラインのdiffをとっているのは徹底していますね!)